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ABSTRACT 


The  purpose  of  this  researeh  is  to  define  a  decision  support  system  for  the 
management  of  a  military  tracked  and  wheeled  vehicle  fleet.  Such  a  system  should  be 
capable  of  delivering  reliable  information  for  decision  making  on  time  and  provides  data 
related  to  the  classification,  registration,  assignment,  maintenance,  and  availability  of 
vehicles.  The  system  is  composed  of  the  following  subsystems: 

•  Subsystem  “Classification  and  Registration  of  tracked  and  wheeled 
vehicles.” 

•  Subsystem  “Transfer  of  tracked  and  wheeled  vehicles.” 

•  Subsystem  “Preventive  and  Curative  Maintenance.” 

•  Subsystem  “Retirement  of  tracked  and  wheeled  vehicles.” 

The  four  subsystems  will  be  installed  in  a  Client  Server  architecture  enabling 
partial  or  total  access  to  the  database  and  providing  real  time  data  for  decision  making. 
The  platform  which  will  host  the  application  is  Oracle  running  on  top  of  the  WINDOWS 
operating  system.  The  database  will  be  relational.  The  framework  used  in  the  design  and 
modeling  consists  of: 

•  Object-Oriented  Analysis  which  aims  to  model  the  problem  domain.  The 
source  of  the  analysis  is  a  written  requirements  statement  and  use  cases. 

•  Oracle  Developer  which  is  a  powerful  tool  for  development  and 
interaction  with  databases. 

The  solution  to  procure  will  be  implemented  and  executed  as  follows: 

•  Client/Server  architecture  with  the  Oracle  DBMS  and  the  development 
tool  Developer  2000. 

•  The  application  will  be  installed  on  the  end  user’s  stations. 

•  The  database  will  be  implemented  on  the  server  side. 

This  software  to  develop  constitutes  a  solution  to  provide  and  make  available 
necessary  and  instantaneous  accurate  data  that  will  be  used  to  derive  the  right  decision  on 
time. 
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I.  INTRODUCTION 


A.  BACKGROUND 

This  project  aims  to  provide  the  Tunisian  Army  with  near  real  time  information 
that  helps  with  decision  making  regarding  the  management  of  the  tracked  and  wheeled 
vehicle  fleet  via  the  architectural  design  of  a  Fleet  Decision  Support  System  (FDSS)  and 
the  design  of  a  centralized  database  for  the  proposed  system. 

From  the  functional  point  of  view,  the  process  of  management  of  the  tracked  and 
wheeled  vehicle  fleet  is  divided  in  four  subsystems:  Registration,  Assignment, 
Maintenance,  and  Retirement.  Each  subsystem  has  its  users  who  need  to  run  modules  of 
the  software  and  have  partial  or  a  complete  access  to  the  database.  This  need  will  be 
accomplished  by  implementing  the  database  on  the  server  side  and  developing  programs 
on  the  client  side  to  query  the  database  and  provide  reliable  information  that  can  be  used 
to  control  and  manage  the  tracked  and  wheeled  vehicle  fleet. 

The  analysis  adopted  in  this  research  is  the  Object  Oriented  Analysis.  The 
purpose  of  this  analysis  is  to  specify  a  Decision  Support  System  including  the  design  of  a 
database  by  using  the  methodology  “MERISE”  in  order  to  specify  the  conceptual  data 
model.  Eor  the  creation,  implementation,  and  management  of  the  database,  the  Oracle 
DBMS  is  used  on  the  server  side.  The  modules  needed  to  interact  with  the  database  are 
realized  with  the  tool  Developer  2000  (Oracle  Eorms). 

B.  SCOPE  OF  THE  THESIS 

The  scope  of  the  thesis  resides  in  the  requirement  analysis  and  architectural 
design  of  the  proposed  Fleet  Decision  Support  System  (FDSS),  to  gather  with  the  design 
of  a  schema  and  prototyping  of  a  database  for  the  proposed  system. 

C.  METHODOLOGY 

Object  Oriented  Methodology  (OOM)  is  a  systematically  development  approach 
encouraging  and  facilitating  the  re-use  of  software  components.  This  methodology  is  a 
powerful  tool  in  modeling  and  structuring  complex  software  systems  and  allows  the 
developer  to  deal  with  the  same  or  very  similar  abstractions  and  entities  during  the 
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complete  proeess  of  software  development.  The  use  of  the  Objeet  Oriented  Methodology 
provides  better  quality,  higher  produetivity,  and  a  low  maintenance  cost  [7]. 


The  advantages  of  using  the  OOA  include: 

•  Code  reuse. 

•  Easier  transformation  from  analysis  to  implementation. 

•  Increased  understanding  of  the  funetional  domain  in  order  to  build  an 
object  oriented  system. 

D,  ENVIRONMENT 

1,  Oracle 

The  Oraele  DBMS  is  one  of  the  most  popular  database  engines.  It  combines  high 
performance,  robustness,  flexibility,  availability,  vivacity,  scalability,  and  modularity. 

2.  Developer  2000 

Oracle  Developer  Suite  is  a  suite  of  development  tools  released  by  the  Oracle 
Corporation.  The  principal  components  were  initially  Oracle  Forms  and  Oraele  Reports. 

E,  ASSUMPTIONS 

Throughout  this  thesis,  it  is  assumed  that  the  reader  is  familiar  with  objeet 
oriented  programming  teehniques,  and  has  a  general  understanding  of  UML 
representation  and  the  SQL  language. 

F,  ORGANIZATION 

This  thesis  is  divided  into  five  ehapters.  Chapter  I  ineludes  the  background  of  the 
problem,  the  area  of  researeh,  the  methodology  used,  and  the  environment.  Chapter  II 
presents  the  requirement  analysis  using  use  eases  and  the  eoneeptual  model.  Chapter  III 
deseribes  the  detailed  design  phase.  Chapter  IV  is  concerned  with  the  prototype 
developed  in  the  Windows  environment  with  Developer  2000  using  the  Oracle  DBMS  to 
manage  the  database.  Chapter  V  provides  a  conelusion  and  reeommendations  for  future 
work. 
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II.  REQUIREMENTS  SPECIFICATION 


The  requirements  intend  to  define  the  speeifications  of  the  system  under 
eonstruction.  They  are  a  deseription  of  the  system  to  be  implemented,  how  it  should  run, 
applieation  domain  information,  and  eonstraints  of  the  system’s  operation.  The 
requirements  speeifieation  is  struetured  and  formalized  during  analysis. 

This  seetion  aims  to  deseribe  and  to  doeument  the  requirements  for  the  new 
Deeision  Support  System  in  order  to  meet  the  desire  of  the  Army’s  traeked  and  wheeled 
vehiele  department.  The  requirements  speeifieation  is  one  of  the  most  important  steps 
when  designing  the  new  system.  These  requirements  provide  more  information  regarding 
the  system  to  make  it  possible  to  begin  eontemplating  the  eoneeptual  model  for  the 
software  engineering  effort. 

The  prineipal  objeetive  of  developing  the  Fleet  Deeision  Support  System  (FDSS) 
in  the  Army’s  tracked  and  wheeled  vehicle  department  is  to  provide  tools  to  investigate 
problems,  to  control  the  usage  of  tracked  and  wheeled  vehicles,  to  make  decisions,  and  to 
control  the  execution  of  the  decision  taken.  The  system  should  provide  a  simple  and 
convivial  graphical  user  interface  that  includes  all  functionalities  of  the  current  system.  It 
should  provide  the  capability  of  code  reuse. 

Due  to  the  variety  of  hardware  used  in  different  Army’s  departments,  the  FDSS  to 
develop  must  be  compatible  with  different  hosts  (desktop,  laptop,  and  notebook)  on  the 
client  side  and  the  enterprise  server  on  the  central  side.  The  system  should  be  able  to 
process  data  in  real  time  and  should  assure  an  acceptable  level  of  usability  based  on  the 
following  hardware  specifications. 

A,  HARDWARE  SPECIFICATION 

1.  Client  Side 

•  Computer  CPU:  Intel  or  compatible  400  MHz  or  higher; 

•  Memory  (RAM):  256  MB; 

•  Hard  Disk  space:  60  GB  or  higher; 

•  Monitor:  800  X  600  or  higher  resolution; 
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•  CD-ROM; 

•  Mouse:  Microsoft  or  compatible. 

2,  Server  Side 

•  Server  architecture:  Intel  or  compatible  2  GHz  or  higher; 

•  Memory  (RAM):  2  GB; 

•  Hard  Disk  space:  2x  120  GB  or  higher; 

•  Monitor:  800  X  600  or  higher  resolution; 

•  CD-ROM; 

•  Mouse:  Microsoft  or  compatible. 

B,  VISION  AND  SCOPE  DOCUMENT 

1,  Fleet’s  Management  Requirements 

a.  Background,  Decision  Support  System  Prospect  and  User  Needs 
The  Army’s  tracked  and  wheeled  vehicle  department  proposes  the 

realization  of  a  new  integrated  system  related  to  the  management  of  tracked  and  wheeled 
vehicles.  The  objectives  of  the  new  system  are  to: 

•  Speed  up  the  information  circuit  in  order  to  ensure  better  management  of 
the  tracked  and  wheeled  vehicle  fleet; 

•  Improve  the  efficiency  of  the  data-processing  tools; 

•  Facilitate  communication  between  different  users; 

•  Provide  the  units  with  their  own  management  tools; 

•  Allow  the  central  site  to  be  the  distributor  of  information. 

b.  Decision  Support  System  Objectives  and  Success  Criteria 

•  Improve  decision  making  ability  by  providing  accurate  data  in  real  time; 

•  Reduce  cost  over  long  term; 

•  Improve  the  schedule  of  maintenance  process  of  tracked  and  wheeled 
vehicles; 

•  Improve  the  degree  of  availability  of  tracked  and  wheeled  vehicles; 

•  Substitute  the  manual  procedures  and  encompass  all  users  to  the  new 
automated  system  for  management  of  the  fleet; 

•  Reach  the  satisfaction  of  users  of  the  new  system. 
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c.  Decision  Support  System  Risks 

Some  users  may  be  afraid  of  the  new  automated  system.  This  may  reduee 
the  users’  satisfaetion  and  has  a  repercussion  on  usage  of  the  new  system. 

2.  Vision  of  the  Solution 

a.  Vision  Statement 

The  FDSS  system  is  a  client-server  application  that  will  integrate  different 
subsystems  to  manage  the  procedures  of  registration,  transfer,  maintenance,  and 
retirement  of  tracked  and  wheeled  vehicles. 

b.  Major  Features 

•  Registration 

•  Classification; 

•  Vehicle  Identification. 

•  Assignment 

•  Transfer  request; 

•  Transfer  decision; 

•  Transfer  bulletin; 

•  Unit’s  inventory. 

•  Maintenance 

•  Preventive  maintenance; 

•  Curative  maintenance. 

•  Retirement 

•  Retirement  request; 

•  Retirement  decision; 

•  Alienation  bulletin. 

3.  Scope  and  Limitation 

Throughout  this  thesis,  it  is  assumed  that  the  reader  is  familiar  with  object 
oriented  programming  techniques  and  has  a  general  understanding  of  UML  notation  and 
SQL  language. 
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C.  SOFTWARE  REQUIREMENT  SPECIFICATIONS 

1.  Introduction 

a.  Objective 

The  Software  Requirement  Speeifications  (SRS)  captures  the  functional 
and  nonfunctional  requirement  for  the  Decision  Support  System.  This  document  is 
planned  to  be  utilized  by  the  project  team  implementing  the  functionalities  of  the  system. 
All  requirements  specified  in  this  report  are  of  high  priority  and  dedicated  for  the 
software  to  be  developed. 

b.  Project  Scope  and  Software  Features 

The  Fleet  Decision  Support  System  (FDSS)  in  the  Army’s  vehicle 
department  will  support  the  grouping  of  distributed  data  sources  into  a  consistent  system 
for  the  management  of  tracked  and  wheeled  vehicle  fleet. 

2,  Overall  Description 

a.  Perspective 

The  FDSS  objective  is  to  integrate  all  functionalities  of  the  management 
of  tracked  and  wheeled  vehicle  fleet  into  a  coherent  system  to  provide  data  that  improve 
the  decision  making  ability  and  better  fleet  management. 

b.  User  Classes  and  Characteristics 

Table  1  lists  user  classes  and  characteristics. 
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User  Classes 

Characteristics 

Provisioning  Service 

The  provisioning  serviee  is  responsible  for  the  management 

of  suppliers  and  purehase  orders. 

Logistic  Service 

The  logistie  serviee  satisfies  all  transfer  requests  that  have 

been  approved  by  the  direetor  of  the  department. 

Technical  Service 

The  teehnical  serviee  is  responsible  for  the  technieal 

aspeets  related  to  the  charaeteristies  of  traeked  and  wheeled 

vehieles  to  purehase  or  distribute  to  units. 

Verification,  And 

Control  Service 

This  serviee  eontrols  all  new  traeked  and  wheeled  vehiele 

speeifieations  in  aeeordanee  with  the  agreement  and 

verifies  maintenanee  operations  in  aeeordanee  with 

preliminary  diagnosties  of  an  expert. 

Maintenance  Service 

The  maintenanee  serviee  eontrols  the  preventive 

maintenanee  proeess  and  the  eurative  maintenanee  proeess 

of  traeked  and  wheeled  vehieles. 

Reparation  Service 

This  serviee  is  linked  to  the  maintenanee  service,  repairs 

tracked  and  wheeled  vehicles  and  assumes  responsibility  of 

retire  aged  and  damaged  tracked  and  wheeled  vehicles. 

Table  1.  User  Classes  and  Characteristics 


c.  Operating  Environment 

•  The  FDSS  should  operate  in  elient-server  arehiteeture  with  a  friendly 
graphieal  user  interfaee. 

•  The  FDSS  system  must  operate  in  a  seeure  transmission  environment  to 
ensure  the  eonfidentiality  and  integrity  of  data  transmitted.  A  eapaeity  link 
of  128  kbps  is  reeommended  between  the  server  side  and  the  elient  side  to 
provide  the  user  with  an  aceeptable  response  time  from  the  system. 

d.  Design  and  Implementation  Constraints 

The  system’s  design,  development,  maintenanee,  and  doeumentation 
should  eonform  to  IEEE  1016  [6]  and  1074  [11]  standards. 
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e.  User  Documentation 

The  system  should  provide  on-line  help  to  the  user  deseribing  system 

funetions. 

f.  Dependencies 

•  The  performanee  of  the  system  depends  on  the  performanee  of  the 
network  and  traffie  congestion  during  sessions  established  between  client 
and  server. 

•  The  operation  of  the  system  depends  in  great  part  on  the  performance  of 
the  database. 

3,  System  Features 

a.  Creation  of  Vehicle  Record 

(1)  Vehicle  Classification.  The  system  should  provide  a 
functionality  to  introduce  categories  of  tracked  and  wheeled  vehicles  managed  by  the 
Army’s  vehicle  department. 

(2)  Vehicle  Technical  ID.  The  system  should  provide  a 
functionality  that  allows  introducing  technical  identification  (license  number,  vehicle  ID 
number,  technical  sheet  number)  of  tracked  and  wheeled  vehicles. 

(3)  Vehicle  Administrative  ID.  The  system  should  provide  a 
functionality  that  allows  specifying  the  administrative  ID  of  the  tracked  and  wheeled 
vehicles.  This  interface  should  contain  the  following  information:  usage  class  (stock, 
training,  daily  usage,  maneuver)  and  sustain  class  (sustained,  not  sustained,  partially 
sustained). 

b.  Vehicle  Assignment 

(1)  Transfer  Request.  The  system  should  provide  a 

functionality  that  allows  keeping  track  of  information  related  to  the  transfer  request  of 
tracked  and  wheeled  vehicles.  This  interface  should  contain  the  following  information: 
category  of  vehicle,  quantity,  unit  requesting  the  transfer,  and  transfer  date. 

(2)  Transfer  Decision.  The  system  should  provide  a 

functionality  that  allows  introducing  approved  transfer  requests  of  tracked  and  wheeled 
vehicles  from  the  central  department  to  the  units.  The  information  needed  is:  tracked  and 
wheeled  vehicle  category,  quantity,  transfer  date,  and  unit  or  regiment  that  profits  from 
the  transfer. 
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(3)  Transfer  Bulletin.  The  system  should  provide  a 
funetionality  that  allows  the  exeeution  of  the  approved  transfer  request.  This  interfaee 
should  eontain  the  following  information;  referenee  deeision  transfer,  vehicle  license 
number,  transfer  date,  and  unit  beneficiary. 

c.  Maintenance 

(1)  Preventive  Maintenance.  The  system  should  provide  a 
functionality  that  allows  the  recording  of  maintenance  operations  applied  to  the  vehicle 
and  the  date  for  the  next  maintenance  operation.  This  interface  primarily  contains  the 
vehicle  ID,  the  date  of  maintenance,  the  preventive  maintenance  cost,  and  a  brief 
description  of  the  maintenance  operations. 

(2)  Curative  Maintenance  Request.  The  system  should  provide 
a  functionality  that  allows  for  keeping  track  of  the  curative  maintenance  request.  This 
interface  should  contain  the  following  information:  reference  request,  date  request, 
designation  of  preliminary  diagnostic,  license  number,  and  current  location  of  the  vehicle. 

(3)  Maintenance  Bulletin.  The  system  should  provide  a 

functionality  that  allows  for  keeping  track  of  the  global  information  related  to  the 
operations  of  curative  maintenance  for  each  vehicle.  This  interface  should  contain  the 
following  information:  reference  number  of  maintenance  request,  license  number, 
maintenance  cost,  maintenance  date,  and  a  brief  maintenance  description. 

d.  Vehicle  Retirement 

(1)  Retirement  Request.  The  system  should  provide  a 

functionality  that  allows  the  introduction  of  information  concerning  the  retirement 
request.  This  interface  should  contain  the  following  information;  reference  of  retirement 
request,  vehicle  license  number,  and  retirement  motivation. 

(2)  Retirement  Decision.  The  system  should  provide  a 

functionality  that  allows  for  creating  the  retirement  decision.  This  interface  should 
contain  the  following  information:  reference  retirement  request,  vehicle  license  number, 
retirement  decision  number,  retirement  decision  date,  and  destination  of  vehicle  to  retire. 
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(3)  Alienation  of  Tracked  and  Wheeled  Vehicles.  The  system 
should  provide  a  functionality  that  allows  updating  the  Army’s  vehicle  department 
inventory  after  the  retirement  of  a  vehicle.  This  interface  should  contain  the  following 
information:  vehicle  license  number,  alienation  motive,  alienation  reference,  and 
alienation  date. 

e.  Vehicle  Inquiry 

(1)  Unit’s  Register.  The  system  shall  provide  a  functionality 
that  provides  the  units  with  their  inventory  of  tracked  and  wheeled  vehicles. 

(2)  Vehicle  Owner  Identification.  The  system  shall  provide  a 
functionality  that  allows  the  Military  Police  identify  the  vehicle  owner  (unit)  by  using  the 
vehicle  license  number. 

4.  Interface  Requirements 

a.  User  Interfaces 

•  The  FDSS  system  screen  displays  should  be  similar  to  the  existing  manual 
forms  to  ensure  an  easy  use  and  utilization  of  those  documents. 

•  The  system  should  provide  help  for  tags  in  the  screen  to  assist  the  users  of 
the  application. 

•  The  graphical  interface  should  allow  free  navigation  and  a  search  for 
information  using  the  keyboard  as  well  as  the  mouse. 

•  The  FDSS  system  should  provide  a  standard  screen  with  menu  bar  and 
should  contain  the  primary  operations  that  the  user  is  allowed  to  perform 
(record,  cancel,  research,  update,  add,  first,  previous,  and  next). 

•  The  FDSS  system  should  provide  an  interface  that  allows  the  Military 
Police  (MP)  to  control  the  traffic  of  military  vehicles  when  they  are  out  of 
their  units. 

•  The  FDSS  system  should  provide  an  interface  that  allows  the  exchange  of 
information  with  other  departments. 

b.  Hardware  Interfaces 
No  hardware  interface  is  needed. 

c.  Communications  Interfaces 

Any  software  or  hardware  upgrade  of  the  FDSS  system  should  be 
preceded  by  a  message  with  information  sent  to  the  system  users. 
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5,  Other  Nonfunctional  Requirements 

a.  Performance  Requirements 

•  The  FDSS  system  should  lodge  100  users  during  the  peak  usage  time  with 
an  estimated  average  session  of  30  minutes. 

•  The  system  should  display  a  eonfirmation  message  to  users  within  five 
seeonds  after  submitting  information  to  the  system. 

b.  Security  Requirements 

•  Users  should  be  authentieated  before  being  able  to  perform  any  operation 
in  the  system. 

•  Users  will  be  allowed  only  one  login  ID. 

•  The  system  should  allowed  units  to  aeeess  their  inventory  of  traeked  and 
wheeled  vehieles. 

•  Military  Poliee  are  allowed  aeeess  to  the  system. 

c.  Software  Quality  Attributes 

•  Availability;  The  system  should  be  available  to  the  users  24/7. 

•  Robustness:  If  a  conneetion  is  broken  during  a  user  session,  the  FDSS 
should  enable  the  user  to  reeover  from  an  ineomplete  transaetion. 

D,  FUNCTIONAL  DECOMPOSITION  DIAGRAM 


The  deeomposition  diagram  shown  in  Figure  1  presents  the  top-down  funetional 
deeomposition  of  the  system.  Moreover,  it  provides  an  outline  for  drawing  the  data  flow 
diagram. 
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E,  USE  CASES 

1.  Use  Case  Diagram 

This  section  presents  fifteen  use  cases  to  identify,  analyze  and  understand  the 
informational  system’s  requirements.  These  use  cases  establish  the  desired  behavior  of 
the  system  for  verifying  and  validating  the  system  architecture.  Each  use  case 
corresponds  to  a  different  functionality.  Only  the  major  steps  that  occur  most  of  the  time 
are  included  in  these  use  cases.  Figure  2  depicts  the  use  case  hierarchy. 
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2,  Use  Case  Narratives 
a.  Create  Catalog 
Use  case  ID:  UC-1 

Use  case  name:  Create  Catalog  Record. _ 

Created  by: _ Chiheb  Saidane _ Last  Updated  by:  Cbibeb  Saidane 

Date  created: _ September  2 _ Date  Last  Updated:  November  17 

Actors: _ Director,  Tecbnical  Service. _ 

Description:  This  use  case  describes  tbe  creation  of  tbe  catalog  record.  Tbe 

Director  of  tbe  department  sends  tbe  approved  classification  of 
tracked  and  wbeeled  vebicles  and  tbe  corresponding  sustain  and 
usage  classes  to  tbe  tecbnical  service  (TS).  A  user  from  tbe  TS 

_ enters  tbe  attributed  classes  to  tbe  database. _ 

Preconditions:  1 .  Vebicle  catalog  record  is  created  and  added  to  tbe  database. 

Post  conditions:  1 .  User  is  autbenticated  and  role  applied. 

_ la.  User  not  logged  in. _ 

Normal  Flow:  1.0  Create  catalog  record. 

1 .  User  chooses  tbe  catalog  form. 

2.  System  displays  the  catalog  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  category  of  vehicle  and 
its  corresponding  usage  class  and  sustain  class. 

5.  System  controls  information  and  adds  them  to  the  database. 

Exceptions:  l.O.E.l  Option  System  Is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0.E.2  System  reject  (step  5). 

1.  System  rejects  information  for  the  reason  that  the  database  is 

_ not  available  now  and  information  is  not  stored. _ 

Includes: _ None _ 

Priority: _ High _ 

Special  1 .  User  from  the  technical  service  shall  be  able  to  cancel  the 

Requirements _ operation  at  any  time  prior  to  completion  of  steep  5. _ 

Technical  Data  Catalog  record:  contains  data  identifying  the  category  of 
vehicle,  its  usage  class  and  sustain  class. 
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b.  Update  Catalog 


Use  case  ID: 

Use  case  name 
Created  by: 
Date  created: 

Actors 

Description: 


Preconditions: 


Post  conditions: 
Normal  Flow: 


Exceptions: 


Includes: 
Priority: 
Special 
Requirements 
Technical  Data 


UC-2 

Update  Catalog  Record. _ 

Last  Updated  by: 

Date  Last  Updated: 

Director,  Technical  Service. _ 

This  use  case  describes  the  procedure  of  updating  the  sustain 
class  and  the  usage  class  of  a  category  of  vehicles.  The  sustain 
class  and  usage  class  are  determined  once  a  year  according  to  the 
program  employ. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  a  user  from  the  technical  service  allowed 
to  update  the  sustain  class  and  usage  class  of  the  category  of 

vehicles. _ 

1 .  Catalog  record  is  updated. 

1 .  User  chooses  the  catalog  form. 

2.  System  displays  the  catalog  form. 

3.  User  chooses  the  select  button. 

4.  System  enables  the  select  mode. 

5.  User  enters  the  information  related  to  the  record  to  be  updated. 

6.  User  pushes  the  search  button. 

7.  System  displays  the  requested  information. 

8.  User  updates  information  related  to  classes. 

9.  System  controls  the  entered  information. 

10.  System  verifies  authorization  for  the  user  to  update 

information  and  update  the  database. _ 

l.O.E.l  Option  System  is  not  available  now  (step  1). 

1.  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0,E,2  System  reject  (step  10). 

1.  System  rejects  update  for  the  reason  that  the  database  is  not 

available  now  and  information  is  not  stored. _ 

None _ 

High _ 

1 .  User  from  the  technical  service  shall  be  able  to  cancel  the 

operation  at  any  time  prior  to  completion  of  step  10. _ 

Catalog  record:  contains  data  identifying  the  category  of 
vehicles,  its  usage  class  and  sustain  class. 


Chiheb  Saidane 
November  17 


Chiheb  Saidane 
September  2 
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c.  Delete  Tracked/Wheeled  Vehicles  Categories 
Use  case  ID:  UC-3 

Use  case  name:  Delete  TrackedA¥heeled  Vehicles  Categories. _ 

Created  by: _ Chiheb  Saidane _ Last  Updated  by:  Cbibeb  Saidane 

Date  created: _ September  2 _ Date  Last  Updated:  November  17 _ 

Actors: _ Director,  Maintenance  Service _ 

Description:  This  use  case  describes  tbe  procedure  for  deleting  a  record  from 

tbe  catalog  related  to  a  category  of  vebicles.  Tbe  maintenance 
service  deletes  tbe  record  of  tbe  specified  category  after  tbe 

_ retirement  of  tbe  last  vebicle  remaining  in  tbe  category  to  delete. 

Preconditions:  1 .  System  is  operational. 

2.  User  is  registered  as  a  user  from  tbe  maintenance  service 
allowed  to  delete  tbe  information  related  to  tbe  category  record. 

Post  conditions:  1 .  Vebicle  category  is  deleted. 

Normal  Flow:  1.0  Delete  tracked/wheeled  vehicles  categories. 

1 .  User  chooses  the  catalog  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  the  select  button. 

4.  User  enters  information  related  to  the  record  to  be  deleted. 

5.  User  pushes  the  execute  button. 

6.  System  displays  information  that  satisfies  the  criteria 
specified. 

7.  User  presses  the  delete  button. 

8.  System  verifies  authorization  for  the  user  to  delete 

_ information  and  update  the  database. _ 

Exceptions:  l.O.E.l  Option  System  is  not  available  now  (step  1). 

1.  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0.E.2  System  reject  (step  10). 

1.  System  rejects  delete  information  for  the  reason  that  the 
database  is  not  available  now  and  information  is  not  deleted. 

Includes: _ None _ 

Priority: _ High _ 

Special  1 .  User  from  the  maintenance  service  shall  be  able  to  cancel  the 

Requirements _ operation  at  any  time  prior  to  completion  of  step  8. _ 

Technical  Data  Catalog  record:  contains  data  identifying  the  category  of 

tracked/wheeled  vehicles,  its  usage  class  and  sustain  class. 
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d. 


Edit  Catalog 
I  UC-4 


Use  case  ID; 

Use  case  name: 

Created  by: 
Date  created: 

Actors 

Description: 

Preconditions: 
Post  conditions: 
Normal  Flow: 


Exceptions: 


Includes: 
Priority: 
Special 
Requirements 
Technical  Data 


Edit  Catalog. 

Last  Updated  by: 

Date  Last  Updated: 

Director,  Technical  Service,  Maintenance  Service. 

This  use  case  describes  the  procedure  for  editing  the  catalog.  The 
procedure  occurs  after  each  update  of  the  catalog.  The  set  of 
records  updated  are  edited  and  distributed  to  the  units. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  allowed  to  edit  the  catalog. _ 

1 .  User  successfully  edits  the  catalog  entry. 

1 .  User  chooses  the  catalog  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  the  select  button. 

4.  System  displays  the  criteria  of  selection  form. 

5.  User  enters  information  related  to  the  records  to  be  edited. 

6.  User  pushes  the  edit  button. 

7.  System  edits  the  information  that  satisfies  the  criteria 
specified. 

l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0.E,2  System  reject  (step  7). 

1.  System  rejects  edits  information  for  the  reason  that  the 

database  is  not  available  now. _ 

None _ 

High _ 

1 .  User  shall  be  able  to  cancel  the  operation  at  any  time  prior  to 

completion  of  step  7. _ 

Catalog  record:  contains  data  identifying  the  category  of 
tracked/wheeled  vehicles,  its  usage  class  and  sustain  class. 


Chiheb  Saidane 
November  17 


Chiheb  Saidane 
September  2 
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e.  Registration 


Use  case  ID; 

Use  case  name: 
Created  by: 
Date  created: 
Actors: 

Description: 


Preconditions: 
Post  conditions: 
Normal  Flow: 


Exceptions: 


Includes: 
Priority: 
Special 
Requirements 
Technical  Data 


UC-5 

TrackedA¥heeled  Vehicle  Registration. 

Last  Updated  by: 

Date  Last  Updated: 

Technical  service,  maintenance  service,  logistic  service, 

verification  and  control  service. _ 

This  use  case  describes  the  events  for  creating  a  tracked/wheeled 
vehicle  record.  The  tracked/wheeled  vehicle  record  is  composed 
of  two  parts.  The  first  part  concerns  the  technical  identification. 
The  second  part  concerns  the  administrative  information. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  technical  service. _ 

1.  Vehicle  is  registered  in  the  system. 

1,0  Create  tracked/wheeled  vehicle  record, 

1 .  User  chooses  the  tracked/wheeled  vehicle  registration  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  concerning  the  identification  of  the 
tracked/wheeled  vehicle  and  specifies  the  corresponding  catalog 
category  to  which  the  tracked/wheeled  vehicle  belongs  to. 
^5^^S^stem_controUJufonnatiun_audstoresJhumJuth£dutaba^e^ 
1,0,E,1  Option  System  is  not  available  now, 

1.  System  informs  User  that  this  option  is  not  available. 

2.1.  User  cancel  request. 

2.2.  System  ends  use  case. 

3.1.  User  requests  to  select  another  option. 

3.2.  System  restarts  use  case. 

1,0,E,2  Can  not  Store  information, 

1.  System  informs  User  that  the  database  is  not  available  now 

and  information  is  not  stored. _ 

None _ 

High _ 

1 .  User  shall  be  able  to  cancel  the  operation  at  any  time  prior  to 

completion  of  step  5. _ 

Tracked/wheeled  vehicle  record:  contains  the  following 
information:  track/wheeled  vehicle  license  number.  Designation, 
Identification  number,  category  of  vehicle,  technical  sheet  ID, 
register  ID,  price,  and  owner. 


Chiheb  Saidane 
November  17 


Chiheb  Saidane 
September  2 
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f.  Transfer  Request 


Use  case  ID: 

Use  case  name 

Created  by: 
Date  created: 

Actors 

Description: 

Preconditions: 

Post  conditions: 
Normal  Flow: 


Exceptions: 


Includes: 
Priority: 
Special 
Requirements 
Technical  Data 


UC-6 

Transfer  Request, 

Last  Updated  by: 

Date  Last  Updated: 

Unit,  Regional  Department. _ 

This  use  case  describes  the  events  for  creating  a  tracked/wheeled 
vehicle  transfer  request  record. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  unit  allowed  in  creating  the 

information  related  to  the  transfer  request. _ 

1 .  Request  is  entered  in  the  system. 

1,0  Create  transfer  request  record, 

1 .  User  chooses  the  transfer  request  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  category  of 
tracked/wheeled  vehicle  and  quantity  requested. 
^5^^S^stem_controUJufonnatiun_andstoresJhumJuth£dutaba^e^ 
1,0,E,1  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0,E,2  System  reject  (step  5). 

1.  System  rejects  creation  for  the  reason  that  the  database  is  not 

available  now  and  information  is  not  stored. _ 

None _ 

High _ 

1 .  User  shall  be  able  to  cancel  the  operation  at  any  time  prior  to 

completion  of  step  5. _ 

Transfer  request  record:  contains  the  following  information: 
request  number,  request  date,  tracked/wheeled  vehicle  category, 
and  quantity  requested. 


Chiheb  Saidane 
November  22 


Chiheb  Saidane 
September  2 
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g.  Transfer  Decision 
Use  case  ID:  UC-7 

Use  case  name:  Transfer  Decision. 

Created  by: _ Chiheb  Saidane _ Last  Updated  by:  Cbibeb  Saidane 

Date  created: _ September  2 _ Date  Last  Updated:  November  22 _ 

Actors: _ Director,  Logistic  Service,  Tecbnical  Service. _ 

Description:  This  use  case  describes  tbe  procedure  for  creating  a  record  for 

tbe  transfer  decision  of  tracked/wbeeled  vebicle  approved  by  tbe 

_ director. _ 

Preconditions:  1 .  System  operational. 

2.  User  is  registered  as  user  from  tbe  logistic  service  allowed  in 

_ creating  tbe  information  related  to  tbe  transfer  decision. _ 

Post  conditions:  1 .  Transfer  decision  is  entered  in  tbe  system. 

Normal  Flow:  1,0  Create  transfer  decision  record, 

1 .  User  chooses  the  decision  transfer  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  category  of  tracked/wheeled 
vehicle  to  transfer,  quantity,  and  decision  date. 

_ 5.  System  controls  information  and  adds  them  to  the  database. 

Exceptions:  l.O.E.l  Option  System  is  not  available  now  (step  1). 

1.  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0.E.2  System  reject  (step  5). 

1.  System  rejects  creation  for  the  reason  that  the  database  is  not 

_ available  now  and  information  is  not  stored. _ 

Includes: _ None _ 

Priority: _ High _ 

Special  1 .  User  of  the  logistic  service  shall  be  able  to  cancel  the 

Requirements _ operation  at  any  time  prior  to  completion  of  step  5. _ 

Technical  Data  Transfer  decision  record:  contains  the  following  information: 

decision  reference,  decision  date,  tracked/wheeled  vehicle 
category,  and  quantity  approved. 
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h.  Transfer  Bulletin 


Use  case  ID; 

Use  case  name; 

Created  by; 
Date  created; 
Actors; 

Description; 

Preconditions; 

Post  conditions; 
Normal  Flow; 


Exceptions; 


Includes; 
Priority; 
Special 
Requirements 
Technical  Data 


UC-8 

Transfer  Bulletin  Record. 

Last  Updated  by; 

Date  Last  Updated; 

Logistic  Service,  Unit,  Technical  Service,  Verification  &  Control 

Service. _ 

This  use  case  describes  the  procedure  of  creating  a  transfer 
bulletin  record.  The  transfer  bulletin  contains  the  information 
related  to  the  tracked/wheeled  vehicle  to  transfer. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  logistic  service  allowed  in 

creating  the  information  related  to  the  transfer  bulletin. _ 

1 .  Transfer  Bulletin  is  entered  in  the  system. 

1,0  Create  transfer  bulletin  record, 

1 .  User  chooses  the  transfer  bulletin  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  transfer  decision; 
reference  number,  tracked/wheeled  vehicle  category,  and 
technical  ID  of  the  tracked/wheeled  vehicle. 

5.  System  controls  information  and  adds  the  bulletin  record  to 

the  database. _ 

l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0,E,2  System  reject  (step  5). 

1.  System  rejects  creation  for  the  reason  that  the  database  is  not 
available  now  and  information  is  not  stored. 

None 

High _ 

1 .  User  of  the  logistic  service  shall  be  able  to  cancel  the 

operation  at  any  time  prior  to  completion  of  step  5. _ 

Transfer  bulletin  record;  contains  information  related  to; 
bulletin  reference,  bulletin  date,  decision  transfer,  beneficiary, 
and  license  number  of  tracked/wheeled  vehicle  to  transfer. 


Chiheb  Saidane 
November  22 


Chiheb  Saidane 
September  2 
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L  Update  Tracked/Wheeled  Vehicle  Record 
Use  case  ID;  UC-9 

Use  case  name;  Update  tracked/wheeled  vehicle  record. 

Created  by; _ Chiheb  Saidane _ Last  Updated  by;  Cbibeb  Saidane 

Date  created; _ September  2 _ Date  Last  Updated;  November  22 _ 

Actors; _ Logistic  Service,  Unit. _ 

Description;  After  creating  tbe  transfer  bulletin,  tbe  logistic  service  user 

updates  tbe  vebicle  record  by  assigning  tbe  vebicle  to  tbe  new 

_ owner. _ 

Preconditions;  1.  System  is  operational. 

2.  User  is  registered  as  user  from  tbe  logistic  service  allowed  in 

_ updating  tbe  vebicle  record. _ 

Post  conditions;  1 .  Vebicle  record  is  updated. 

Normal  Flow;  1,0  Update  tracked/wheeled  vehicle  record, 

1.  User  chooses  the  Vehicle  option. 

2.  System  displays  the  selected  form. 

3.  User  enters  information  related  to  the  record  to  be  updated. 

4.  System  displays  the  vehicle  record  to  be  updated. 

5.  User  updates  the  vehicle  owner  field. 

_ 6.  System  controls  information  and  updates  the  vehicle  record. 

Exceptions;  1,0,E,1  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0,E,2  System  reject  (step  6). 

1 .  System  rejects  edits  of  information  for  the  reason  that  the 

_ database  is  not  available  now. _ 

Includes; _ None _ 

Priority; _ High _ 

Special  1 .  User  of  the  logistic  service  shall  be  able  to  cancel  the 

Requirements  operation  at  any  time  prior  to  completion  of  step  6. 

Technical  Data  Tracked/wheeled  vehicle  record:  contains  the  following 

information;  license  number,  Designation,  Identification 
number,  category  of  vehicle,  technical  sheet  ID,  register  ID, 
price,  and  owner. 
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Create  Preventive  Maintenance  Record 


Use  case  ID; 

Use  case  name: 

Created  by: 
Date  created: 

Actors: 

Description: 

Preconditions: 

Post  conditions; 
Normal  Flow: 


Exceptions: 


Includes: 
Priority: 
Special 
Requirements: 
Technical  Data 


UC-10 

Preventive  Maintenance  Record. 

Last  Updated  by: 

Date  Last  Updated: 

Reparation  Service,  Unit. _ 

This  use  case  describes  the  events  of  creating  a  preventive 
maintenance  record  for  the  tracked/wheeled  vehicle. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  reparation  service  allowed 

in  creating  the  preventive  maintenance  record. _ 

1 .  Preventive  maintenance  record  is  created. 

1,0  Create  tracked/wheeled  vehicle  maintenance  record. 

1 .  User  chooses  the  preventive  maintenance  form. 

2.  System  displays  the  corresponding  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  preventive  maintenance 
for  the  tracked/wheeled  vehicle. 

_5^_S^stem_controUJuformafiun_audstoresJhumJuth£dutaba^e^ 
l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0,E,2  System  reject  (step  6). 

1.  System  rejects  creation  for  the  reason  that  the  database  is  not 

available  now  and  information  is  not  stored. _ 

None _ 

High _ 

1 .  User  of  the  reparation  service  shall  be  able  to  cancel  the 

operation  at  any  time  prior  to  completion  of  step  5. _ 

Preventive  maintenance  record:  contains  information  related 
to  the  ID  of  tracked/wheeled  vehicle  subject  of  preventive 
maintenance,  preventive  acts  applied,  maintenance  amount, 
maintenance  date,  and  provisional  date  of  next  maintenance. 


Chiheb  Saidane 
November  22 


Chiheb  Saidane 
September  2 
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Use  case  ID; 


Curative  Maintenance  Request 
I  UC-11 


Use  case  name 

Curative  Maintenance  Request, 

Created  by; 

Chiheb  Saidane 

Last  Updated  by; 

Chiheb  Saidane 

Date  created; 

September  2 

Date  Last  Updated; 

November  23 

Actors 

Maintenance  Service,  Unit. 

Description; 

Unit  formulates  a  request  to  repair  tracked/wheeled  vehicle.  The 
request  describes  briefly  the  tracked/wheeled  vehicle  problem. 

Preconditions; 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  reparation  service  allowed 
in  creating  the  curative  maintenance  request  record. 

Post  conditions; 

1 .  Curative  maintenance  request  record  is  created. 

Normal  Flow; 

1,0  Curative  maintenance  request, 

1 .  User  chooses  the  maintenance  request  form. 

2.  System  displays  the  maintenance  request  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  maintenance  request. 

5.  System  controls  the  information  added. 

6.  System  stores  information  in  the  database. 

Exceptions; 

1,0,E,1  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0,E,2  System  reject  (step  6). 

1.  System  rejects  creation  for  the  reason  that  the  database  is  not 
available  now  and  information  is  not  stored. 

Includes; 

None 

Priority; 

High 

Special 

Requirements; 

1.  User  of  the  reparation  service  shall  be  able  to  cancel  the 
operation  at  any  time  prior  to  completion  of  step  6. 

Technical  Data 

Maintenance  request  record:  contains  information  related  to 
the  identification  of  tracked/wheeled  vehicle  to  fix,  maintenance 
request  date,  problem  description,  and  beneficiary. 
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Create  Maintenance  Bulletin 


Use  case  ID; 

Use  case  name; 

Created  by; 
Date  created; 

Actors; 

Description; 


Preconditions; 


Post  conditions; 
Normal  Flow; 


Exceptions; 


Includes; 
Priority; 
Special 
Requirements; 
Technical  Data 


UC-12 

Create  Maintenance  Bulletin, 

Chiheb  Saidane 

Last  Updated  by; 

Chiheb  Saidane 

September  2 

Date  Last  Updated; 

November  23 

Reparation  Service. 

After  repairing  the  tracked/wheeled  vehicle,  the  employee 
mentions  the  cost  of  the  repair  operation.  The  reparation  service 
introduces  the  maintenance  request  reference,  acts  of 
maintenance  achieved,  cost  of  maintenance,  and  date  of 
maintenance. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  reparation  service  allowed 
in  creating  the  curative  maintenance  request  record. 

1 .  Maintenance  bulletin  is  created. 

1,0  Create  maintenance  bulletin. 

1 .  User  chooses  the  maintenance  bulletin  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  maintenance  operation. 

5.  System  controls  information  and  adds  them  to  the  database. 

l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0,E,2  System  reject  (step  5). 

1.  System  rejects  information  for  the  reason  that  the  database  is 

not  available  now  and  information  is  not  stored. _ 

None _ 

High _ 

1.  User  of  the  reparation  service  shall  be  able  to  cancel  the 

operation  at  any  time  prior  to  completion  of  step  5. _ 

Maintenance  bulletin  record;  contains  information  related  to; 
license  number  of  the  vehicle,  acts  of  maintenance  applied,  and 
maintenance  amount. 
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m.  Retirement  Request 


Use  case  ID; 

Use  case  name; 

Created  by; 
Date  created; 

Actors; 

Description; 

Preconditions; 

Post  conditions; 
Normal  Flow; 


Exceptions; 


Includes; 
Priority; 
Special 
Requirements; 
Technical  Data 


UC-13 

Retirement  Request. 

Last  Updated  by; 

Date  Last  Updated; 

Unit,  Expert,  Reparation  Service. _ 

This  use  case  describes  the  procedure  for  creating  a  retirement 
request  when  the  tracked/wheeled  vehicle  is  aged  or  seriously 
damaged  and  the  maintenance  is  very  expensive. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  reparation  service  allowed 

in  creating  the  retirement  request  record. _ 

1 .  Retirement  request  record  is  created. 

1.0  Retirement  request. 

1.  User  chooses  the  retirement  request  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  information  related  to  the  tracked/wheeled  vehicle 
to  retire. 

5.  System  controls  information  and  creates  the  retirement  request 

record. _ 

l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0.E.2  System  reject  (step  5). 

1.  System  rejects  information  for  the  reason  that  the  database  is 

not  available  now  and  information  is  not  stored. _ 

None _ 

High _ 

1.  User  of  the  reparation  service  shall  be  able  to  cancel  the 

operation  at  any  time  prior  to  completion  of  step  5. _ 

Retirement  request  record;  contains  information  concerning 
the  tracked/wheeled  vehicle  to  retire,  motive  of  retirement, 
retirement  request  date,  and  the  unit  origin  of  the  retirement 
proposal. 


Chiheb  Saidane 
November  23 


Chiheb  Saidane 
September  2 
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n.  Retirement  Decision 
Use  case  ID;  UC-14 

Use  case  name:  Retirement  Decision. _ 

Created  by: _ Chiheb  Saidane _ Last  Updated  by:  Cbibeb  Saidane 

Date  created: _ September  2 _ Date  Last  Updated:  November  23 _ 

Actors: _ Maintenance  Service,  Director. _ 

Description:  This  use  case  describes  tbe  procedure  of  creating  tbe  retirement 

decision  record  when  tbe  Director  decides  tbe  retirement  of  tbe 

_ tracked/wbeeled  vebicle  subject  to  tbe  retirement  request. _ 

Preconditions:  1 .  System  is  operational. 

2.  User  is  registered  as  user  from  tbe  maintenance  service 

_ allowed  in  creating  tbe  retirement  decision  record. _ 

Post  conditions;  1 .  Retirement  decision  successfully  entered  in  tbe  system. 

Normal  Flow:  1.0  Retirement  decision. 

1.  User  chooses  tbe  retirement  decision  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  the  add  button. 

4.  User  enters  information  related  to  the  tracked/wheeled  vehicle 
to  retire. 

5.  System  controls  information  and  creates  the  retirement 

_ decision  record. _ 

Exceptions:  l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1.0.E.2  System  reject  (step  5). 

1.  System  rejects  creation  for  the  reason  that  the  database  is  not 

_ available  now  and  information  is  not  stored. _ 

Includes: _ None _ 

Priority: _ High _ 

Special  1 .  User  of  the  maintenance  service  shall  be  able  to  cancel  the 

Requirements: _ operation  at  any  time  prior  to  completion  of  step  5. _ 

Technical  Data  Retirement  decision  record;  contains  information  mentioning 

the  tracked/wheeled  vehicle  to  retire,  reference  of  the  retirement 
request,  and  date  of  the  retirement  decision. 
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o. 


Alienation  Bulletin 


Use  case  ID; 

Use  case  name 
Created  by: 
Date  created: 

Actors 

Description: 

Preconditions: 

Post  conditions: 
Normal  Flow: 


Exceptions; 


Includes: 
Priority: 
Special 
Requirements: 
Technical  Data 


UC-15 

Alienation  Bulletin.  _ 

Last  Updated  by: 

Date  Last  Updated: 

Maintenance  Service,  Provision  Service. 

After  the  execution  of  the  retirement  procedure,  the 
tracked/wheeled  vehicle  is  deleted  from  the  department 
inventory. _ 

1 .  System  is  operational. 

2.  User  is  registered  as  user  from  the  maintenance  service 

allowed  in  creating  the  alienation  record. _ 

1.  Vehicle  record  is  deleted  from  the  system. 

1,0  Alienation  of  a  tracked/wheeled  vehicle, 

1.  User  chooses  the  alienation  record  form. 

2.  System  displays  the  chosen  form. 

3.  User  chooses  add  button. 

4.  User  enters  the  reference  number  of  the  retirement  decision 
and  information  related  to  the  tracked/wheeled  vehicle  to  retire. 

5.  System  controls  information  and  adds  them  to  the  database 

6.  System  deletes  tracked/wheeled  vehicle  record  from  the 
department  account. 

l.O.E.l  Option  System  is  not  available  now  (step  1). 

1 .  System  notifies  user  that  this  option  is  not  available. 

2a.  User  requests  to  select  another  option. 

2b.  System  restarts  use  case. 

1,0,E,2  System  reject  (step  5). 

1.  System  rejects  creation  and  deletion  operations  for  the  reason 

that  the  database  is  not  available. _ 

None _ 

High _ 

1 .  User  of  the  maintenance  service  shall  be  able  to  cancel  the 

operation  at  any  time  prior  to  completion  of  step  6. _ 

Alienation  bulletin  record;  contains  information  concerning  the 
decision  reference  of  the  tracked/wheeled  vehicle  retired,  the 
alienation  date,  and  the  reference  of  alienation  bulletin. 


Chiheb  Saidane 
November  23 


Chiheb  Saidane 
September  2 
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F. 


SEQUENCE  DIAGRAMS 


User 

I _ 1 :  SelectCatalogOption( ) 

<: _ 1:..  DisBlay.  Qataioa  _  form, . 

_ 3:  PressAddButton( ) 

/  4:  Provide  Create  Mode 


5:  InputCatalogDataf ) 


6:  Data  eontroled 
7:  ValidateeatalogDataC ) 

8 ;  .Data  Recorded 
*  Until  done 


System 


Figure  3.  Sequence  Diagram  SD-1.1:  Create  Catalog 


O 

f  I - 

Tjser  System 


1 :  SelectCatalogOption( ) 


2:  Display  catalog  form 

— > 

\ 

3:  PressSelectButton( ) 

\  r 

: 

4:  Provide  Select  mode 

y 

1 

5:  EnterResearchCriterial ) 

6:  Display  Catalog  Data 

y 

7:  UpdateCatalogData( ) 

\r 

8:  Data  Controlled 

\ 

9:  ValidateUpdateCatalogDataf ) 

\  r 

<--  - 

10;  Data  Updated 

y 

*  Until  done 


Figure  4,  Sequence  Diagram  SD-2.2:  Update  Catalog 
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o 

User 

1 ;  SelectCatalogOptionf ) 
2;  Display  Catalog  Form 
^  3;  Press  SelectButton( ) 


4;  Provides  Select  Mode 


5;  EnterResearchCriteriaf ) 


6;  Display  Catalog  Data 

- > 

\ 

7;  DeleteCatalogDataf ) 

\i-i 

8;  Verify  Data 

9:  Confirm  Delete  Data(  ) 

10:  Data  Deleted 

*  Until  done 


Figure  5,  Sequence  Diagram  SD-3,3:  Delete  Catalog 


System 


-> 


D 


-> 


Vser 


r 


<- 


u<-. 


<- 


<- 


1 ;  SelectCatalogOptionf ) 


2 ;  Display  Cat_alo^_Fprni 
3:  PressSelectButtonf ) 


4:  Provides  Select  Mode 


5:  EnterResearchCriteria( ) 


6:  Info  Data  Eound 
7:  EditCatalogf ) 


8:  Catalog  Info 

*  Until  done 


System 


-> 


-> 


-> 


-> 


Figure  6,  Sequence  Diagram  SD-4,4:  Edit  Catalog 


30 


User 


r' 


<- 


U<L-: 


<- 


<- 


2:  Display VehicleForm 


3:  Press AddButton( ) 


4:  ProvidesCreateMode 


5:  ProvideVehicleInfol ) 


6;  Vehicle  Info  Controlled 


7:  ValidateVehiclePatat  I 


8:  Data  Recorded 


Until  done 


System 


1:  SelectVehicleIdentificationOption( ) 


■> 


-> 


-> 


->1 


Figure  7.  Sequence  Diagram  SD-5,5:  Registration 


User 


System 


. 

1 :  SelectTransferRequestOption( ) 

\  r 

<<  __  __ 

2:  Display  Transfer  Request  Form 

y 

\ 

3:  Press AddButtonf ) 

\ 

-i 

4;  Proyide  Add  Mode 

y 

1 

5:  SubmitTransferInfol ) 

\  r 

6;  Data  Controlled 

y 

7:  ValidateTransferInfol ) 

\ 

8;  Data  Recorded 

y 

*  Until  done 

1 


j 


Figure  8,  Sequence  Diagram  SD-6,6:  Transfer  Request 
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User 


<- 


r' 


<- 


1:  SelectTransferDecisionOption( ) 


2:  Display  Transfer  Decision  Form 
3:  PressAddButton( ) 


4;  ProvidesAddMode 


System 


-> 


-> 


<- 


<- 


L. 


5:  InputTransferDecisionDatal ) 


6:  Data  Controlled 


7:  ValidateTransferDecisionDatal ) 


8:  Data  Recorded 


*  Until  done 


Figure  9, 


Sequence  Diagram  SD-7.7:  Transfer  Decision 


r 


User 


System 


1 :  SelectTransferBulletinOption( ) 


2:  Display  Transfer  Bulletin  Form 

- > 

3:  PressIAddButton( ) 

4:  Provide  Add  Mode 

y 

5:  SubmitTransferBulletinDataO 

> 

6:  Data  Controlled 

7:  ValidateTransferBulletindatal ) 

8:  Data  Added 

y 

*  Until  done 

Figure  10,  Sequence  Diagram  SD-8,8:  Assignment 
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Figure  11.  Sequence  Diagram  SD-9.9:  Update  Vehicle  Owner 
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Figure  13,  Sequence  Diagram  SD-11.1:  Curative  Bulletin 


Figure  14,  Sequence  Diagram  SD-12,1:  Maintenance  Request 
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*  Until  done 


_ I 

Figure  15,  Sequence  Diagram  SD-13,1:  Retirement  Request 


o 


*  Until  done 


Figure  16.  Sequence  Diagram  SD-14.1:  Retirement  Decision 
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Figure  17.  Sequence  Diagram  SD-15.1:  Alienation  of  a  vehicle 


G.  DATA  MODELING  AND  ANALYSIS 

A  data  model  is  a  plan  for  building  a  database.  To  be  effective,  it  must  be  simple 
enough  to  communicate  the  data  structure  required  by  the  database  to  the  end  user  and 
detailed  enough  for  the  database  designer  to  use  to  create  the  physical  structure.  The  data 
structures  include  the  data  objects,  the  associations  between  data  objects,  and  the  rules 
which  govern  operations  on  the  objects  [15]. 

The  goal  of  the  data  model  is  to  make  sure  that  all  data  objects  required  by  the 
database  are  completely  and  accurately  represented.  Because  the  data  model  uses  easily 
understood  notations  and  natural  language,  it  can  be  reviewed  and  verified  as  correct  by 
the  end-users.  Data  modeling  is  probably  the  most  labor  intensive  and  time  consuming 
part  of  the  development  process. 

The  data  model  acts  as  a  framework  for  the  development  of  the  new  or  enhanced 
application.  There  are  two  major  methodologies  used  to  create  a  data  model;  the  Entity- 
Relationship  (ER)  approach  and  the  Object  Model.  This  thesis  uses  the  Entity- 
Relationship  (ER)  approach  [17]. 
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1,  How  are  Data  Models  Used  in  Practice? 

There  are  three  basic  styles  of  data  models: 

•  Conceptual  data  model  (CDM):  A  CDM  represents  the  overall  logical 
structure  of  a  database,  which  is  independent  of  any  software  or  data 
storage  structure.  A  conceptual  model  often  contains  data  objects  not  yet 
implemented  in  the  physical  database.  It  gives  a  formal  representation  of 
the  data  needed  to  run  an  enterprise  or  a  business  activity. 

•  Logical  data  model  (LDM):  LDM  is  used  to  explore  the  domain  concepts 
and  their  relationships.  The  LDM  depicts  the  logical  entity  types,  typically 
referred  to  simply  as  entity  types,  the  data  attributes  describing  those 
entities,  and  the  relationships  between  the  entities. 

•  Physical  data  model  (PDM):  PDM  is  used  to  design  the  internal  schema 
of  a  database,  depicting  the  data  tables,  the  data  columns  of  those  tables, 
and  the  relationships  between  the  tables  [15]. 

2,  Conceptual  Data  Model  Representation  for  the  FDSS 

The  conceptual  data  model  (Figure  18)  for  the  Decision  Support  System  is 
virtually  divided  into  four  parts.  The  first  part  concerns  tracked/wheeled  vehicle 
registration  (Figure  19).  The  second  part  concerns  the  transfer  process  (Figure  20).  The 
third  part  handles  the  maintenance  of  the  tracked/wheeled  vehicle  (Figure  21).  The  fourth 
part  concerns  the  retirement  process  of  the  tracked/wheeled  vehicle  (Figure  22). 

The  data  model  has  two  outputs.  The  first  is  an  entity-relationship  diagram  which 
represents  the  data  structures  in  a  pictorial  form  (Figures  27,  28,  29,  30).  The  second  is 
the  data  dictionary  which  contains  the  details  required  for  the  construction  of  the  physical 
database. 
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Figure  18,  Conceptual  Data  Model  Representation  (FDSS) 
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Figure  19,  Conceptual  Data  Model  Representation  (Registration) 


Figure  20,  Conceptual  Data  Model  Representation  (Transfer) 


39 


Figure  21,  Conceptual  Data  Model  Representation  (Maintenance) 


Figure  22,  Conceptual  Data  Model  Representation  (Retirement) 
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3,  Data  Dictionary 

A  data  dictionary  is  a  structured  collection  of  data  element  names  and  definitions. 
It  may  illustrate  all  the  data  holdings  of  an  organization,  a  part  of  the  holdings  or  a  single 
database.  More  advaneed  data  dietionaries  ean  eontain  database  schema  with  reference 
keys  and  entity  relationships. 

A  data  dictionary  is  used  to  identify  the  data  and  the  databases  that  eontain  it.  The 
data  dictionary  identifies  data  elements  and  their  attributes  including  names,  definitions 
and  units  of  measure  and  other  information  [16]: 

•  Data  Element  Domain:  The  context  within  which  the  data  element  exists. 

•  Data  Element  Name:  Unique  data  element  name  from  the  application 
domain.  This  is  the  actual  name  of  this  data  element. 

•  Data  Element  Definition:  Description  of  the  meaning  of  the  data 
element. 

•  Data  Element  Field  Name(s):  Field  names  are  the  names  used  for  this 
element  in  eomputer  programs  and  database  sehemas.  These  are  the 
teehnieal  names,  often  limited  by  the  programming  languages  and 
systems. 

•  Data  Element  Data  Type:  Data  type  (characters,  numerie,  etc.),  size  and, 
if  needed,  any  special  representation.  Common  programming  notation, 
input  masks,  etc  can  be  used. 

The  Appendix  shows  the  list  of  data  eolleeted  for  the  FDSS  system. 

H.  SYSTEM  OPERATION  CONTRACTS 
Contract: 

C-1  InputCatalogData(cod_lin,  lab_lin,cod_usg,  cod  sust). 

Cross  References: 

-  UC-1  Create  Catalog  Reeord. 

-  SD-1.1  Create  Catalog. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instanee  u  of  Usage  Class  exists. 

3.  An  instance  s  of  Sustain  Class  exists. 
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Post-conditions: 

1 .  A  new  instance  c  of  Catalog  is  created. 

2.  The  FDSS  informs  the  user  about  the  creation  completion. 


Contract: 

C-2  UpdateCatalogData(cod_lin,  cod_usg,  cod  sust). 
Cross  Reference: 

-  UC-2  Update  Catalog  Record. 

-  SD-2.2  Update  Catalog. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  c  of  Catalog  exists. 

2.  An  instance  u  of  Usage  Class  exists. 

3.  An  instance  s  of  Sustain  Class  exists. 

Post-conditions: 

1 .  The  instance  c  of  Catalog  is  updated. 

2.  The  FDSS  informs  the  user  of  the  update  completion. 


Contract: 

C-3  DeleteCatalogData(cod_lin,  lab  li,  cod  usg,  cod  sust). 
Cross  References: 

-  UC-3  Delete  Tracked/Wheeled  Vehicles  Categories. 

-  SD-3.3  Delete  Catalog  Line. 

Pre-conditions: 

1.  FDSS  is  operational. 
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2.  An  instance  c  of  Catalog  exists. 

3.  No  instances  v  of  Vehiele  belong  to  this  elass. 

Post-conditions: 

1 .  The  instance  c  of  Catalog  is  destroyed. 

2.  The  FDSS  informs  the  user  of  the  destroy  completion. 


Contract: 

C-4  EditCatalogData(cod_lin,  lab  li,  cod  usg,  eod  sust). 
Cross  References: 

-  UC-4  Edit  Catalog. 

-  SD-4.4  Edit  Catalog  Eines. 

Pre-conditions: 

1.  EDSS  is  operational. 

2.  An  instanee  c  of  Catalog  exists. 

Post-conditions: 

1 .  The  instanee  c  of  Catalog  is  seleeted. 

2.  The  EDSS  edit  the  data  of  the  c  instanee. 

3.  The  EDSS  informs  the  user  of  the  edit  completion. 


Contract: 

C-5  ProvideVehicleInfo(nbr_lic,  id  veh,  eod  lin,  ful_typ,  num  tsht, 
nbr  reg,  unit_prc,  geo_pos,  cod  unit). 

Cross  References: 

-  UC-5  Tracked/Wheeled  Vehicle  Registration. 

-  SD-5.5  Registration. 
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Pre-conditions: 


1.  FDSS  is  operational. 

2.  An  instance  c  of  Catalog  exists. 

3.  An  instance  r  of  Central  Register  exists. 

4.  An  instance  t  of  Technical  Sheet  exists. 

5.  An  instance  un  of  Unit  exists. 

Post-conditions: 

1.  A  new  instance  v  of  Vehicle  is  created. 

2.  The  FDSS  informs  the  user  of  the  creation  completion. 


Contract: 

C-6  SubniitTransfcrInfo(num_t_rq,  t_rq_dt,  cod  lin,  qte_t_req, 
codunit). 

Cross  References: 

-  UC-6  Transfer  Request. 

-  SD-6.6  Tracked/Wheeled  Vehicle  Request. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  Instance  c  of  Catalog  exists. 

3.  An  instance  un  of  Unit  exists. 

Post-conditions: 

1.  A  new  instance  tr  of  Transfer  Request  is  created. 

2.  For  each  instance  c  of  the  Catalog  Line  selected  a  new  instance  rl  of  the 
Transfer  Request  Line  is  created. 
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3.  The  FDSS  informs  the  user  of  the  creation  success. 


Contract 

C-7  InputTransferDecisionData(num_t_dec,  t_dec_dt,  d_trs_obs, 
num  t  rq,  cod  lin,  obj  t  dec). 

Cross  References: 

-  UC-7  Transfer  Decision. 

-  SD-7.7  Transfer  Decision. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  Instances  c  of  Catalog  exist. 

3.  An  instance  tr  of  Transfer  Request  exists. 

Post-conditions: 

1.  A  new  instance  td  of  Transfer  Decision  is  created. 

2.  For  each  instance  c  of  Catalog  specified  a  new  instances  dl  of  the 
Decision  Line  is  created. 

3.  The  FDSS  informs  the  user  of  the  creation  completion. 

Contract: 

C-8  SubmitTransferBulletinData(num_bul,  nbr  lic,  Dat  bul, 
num  tdec,  cod  unt). 

Cross  References: 

-  UC-8  Transfer  bulletin. 

-  SD-8.8  Assignment  of  Vehicle. 

Pre-conditions: 


1.  FDSS  is  operational. 
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2.  An  instance  un  of  Unit  exists. 


3.  Instances  v  of  Vehicle  exists. 

4.  An  instance  td  of  Transfer  Deeision  exists. 

Post-conditions: 

1.  A  new  instance  tb  of  Transfer  Bulletin  is  ereated. 

2.  For  eaeh  instance  v  of  Vehiele  specified  a  new  instances  dt  of  Detail 
Transfer  Bulletin  is  ereated. 

3.  The  FDSS  informs  the  user  of  the  creation  sueeess. 


Contract: 

C-9  UpdateVehicleOwner(nbr_lic,  eod  unit). 
Cross  Reference: 

-  UC-9  Update  traeked/wheeled  vehicle  record. 

-  SD-9.9  Update  vehicle  owner. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  tb  of  Transfer  Bulletin  exists. 

3.  An  instanee  dt  of  Detail  Transfer  exists. 

4.  An  instance  v  of  Vehiele  exists. 

Post-conditions: 

1.  The  instance  v  of  Vehicle  is  updated. 

2.  The  FDSS  informs  the  user  of  the  update  completion. 
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Contract: 


C-10  InputPreventiveMaintenanceData(num_pr_bul,  nbr  lic 

,pr_bt_dt,  pr  b  amt,  nwpr  dat,  cd_p_act,  p_prt_mt). 

Cross  References 

-  UC-10  Preventive  Maintenance  Record. 

-  SD-10.1  Preventive  Maintenance. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  v  of  Vehicle  exists. 

3.  An  instance  pa  of  Preventive  Act  exists. 

Post-conditions: 

1 .  A  new  instance  pb  of  Preventive  Bulletin  is  created. 

2.  For  each  instance  pa  of  Preventive  Act  specified  a  new  instance  p  of 
perform  is  created. 

3.  The  FDSS  informs  the  user  of  the  creation  success. 


Contract: 

C-11  ProvideCurativeMaintenanceActInfo(num_Rbul,  r  bul  dt, 

num  mreq,  t_rpamt,  c_cu_act,  mt_r_act,  wk  desc). 

Cross  References: 

-  UC-12  Create  Maintenance  Bulletin. 

-  SD-11.1  Curative  Bulletin. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  v  of  Vehicle  exists. 


47 


3.  An  instance  mr  of  Maintenance  Request  exists. 

4.  An  instance  ca  of  Curative  Act  exists. 

Post-conditions: 

1.  A  new  instance  rb  of  Reparation  Bulletin  is  created. 

2.  For  each  instance  ca  of  Curative  Act  entered  a  new  instance  r  of  Repair 
is  created. 

3.  The  FDSS  informs  the  user  of  the  creation  success. 

Contract: 

C-12  InputMaintenanceRequestData(num_mreq,  nbr  lic,  nbr  m  st, 
m_req_dt,  obs  rnreq). 

Cross  References: 

-  UC-1 1  Curative  Maintenance  Request  Record. 

-  SD-12.1  Maintenance  Request. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  v  of  Vehicle  exists. 

Post-conditions: 

1.  A  new  instance  mr  of  Maintenance  Request  is  created. 

2.  The  FDSS  informs  the  user  of  the  creation  completion. 

Contract: 

C-13  SubmitRetirementRequestData(num_r_rq,  nbr  lic,  r_req_dt, 
mot  ref,  r-rq_obs,  cod  unit). 

Cross  References: 

-  UC-1 3  Retirement  Request. 
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-  SD-13.1  Retirement  Request. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  v  of  Vehicle  exists. 

3.  An  instance  un  of  Unit  exists. 

Post-conditions: 

1.  A  new  instance  rr  of  Retirement  Request  is  created. 

2.  The  FDSS  informs  the  user  of  the  creation  completion. 

Contract: 

C-14  InputRetirementDecisionData(nm_rf_dec,  num  r  rq,  r  dec  dt, 
orfdec). 

Cross  References: 

-  UC-14  Retirement  Decision. 

-  SD-14.1  Retirement  Decision. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  rr  of  Retirement  Request  exists. 

Post-conditions: 

1.  A  new  instance  refd  of  Retirement  Decision  is  created. 

2.  The  FDSS  informs  the  user  of  the  creation  completion. 

Contract: 

C-15  SubniitAlienationBulletinInfo(num_bl_al,  nm  rf  dec,  a  bul  dt). 
Cross  References: 
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-  UC-15  Retirement  Deeision. 


-  SD-15.1  Alienation  of  a  Vehicle. 

Pre-conditions: 

1.  FDSS  is  operational. 

2.  An  instance  refd  of  Retirement  Decision  exists. 

Post-conditions: 

1 .  A  new  instance  ab  of  Alienation  Bulletin  is  created. 

2.  An  instance  v  of  Vehicle  is  deleted. 

3.  The  FDSS  informs  the  user  of  the  creation  completion. 
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III.  DESIGN  PHASE 


A.  APPLICATION  ARCHITECTURE  AND  IMPLEMENTATION 

1.  Description 

In  the  FDSS  system  environment,  which  is  an  Oracle  environment,  the  FDSS 
application  and  the  FDSS  database  are  separated  into  two  parts:  the  front-end  or  client 
portion,  and  the  back-end  or  server  portion.  The  client  runs  the  FDSS  application  that 
accesses  the  FDSS  database  information  and  interacts  with  the  user  through  the  keyboard, 
screen,  and  mouse.  The  server  runs  the  Oracle  software  and  handles  the  functions 
required  for  concurrent,  shared  data  access  to  the  database.  Figure  23  illustrates  the 
architecture  of  the  system  where  the  client  and  server  are  located  on  different  computers, 
and  these  computers  are  connected  through  a  network.  The  server  and  clients 
communicate  through  Oracle  Net  Services,  Oracle's  network  interface. 


Database  Server 


Figure  23.  FDSS  Client/Server  Architecture  (From:  [13]) 
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2,  The  Use  of  Oracle  Net  Services  in  the  FDSS  System 

a.  Support  Network 

Oracle  Net  Services  enables  a  network  session  from  the  client  FDSS 
application  to  the  FDSS  database.  It  is  responsible  for  establishing  and  maintaining  the 
connection  between  the  application  and  database  server. 

b.  How  Oracle  Net  Services  Works  in  the  FDSS  System 

Oraele's  support  network  protoeols  provides  an  interfaee  between  Oracle 
processes  running  on  the  database  server  and  the  FDSS  application  running  on  other 
computers  of  the  network.  Oracle  protoeols  take  SQL  statements  from  the  interfaee  of  the 
FDSS  application  and  package  them  for  transmission  to  Oracle  through  the  supported 
higher  level  protocols.  The  protocols  also  take  replies  from  Oracle  and  package  them  for 
transmission  to  the  application  through  the  same  higher  level  communications 
mechanism  [14]. 

c.  Stack  Communication  for  the  FDSS  Client/Server  Application 
Connections 

Figure  24  illustrates  the  various  layers  on  the  client  and  on  the  database 
server  after  a  connection  has  been  established. 
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Figure  24,  Identification  of  Layers  used  in  the  FDSS  Client/Server  Application 

Connection  (After  [14]) 
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During  a  session  with  the  database,  the  FDSS  client  uses  Oracle  Call 
Interface  (OCI)  to  interact  with  the  database  server.  OCI  is  a  software  component  that 
provides  an  interface  between  the  FDSS  client  application  and  the  SQL  language  that  the 
database  server  understands. 

The  presentation  layer  used  by  the  FDSS  client/server  application  is  Two- 
Task  Common  (TTC).  TTC  provides  character  set  and  data  type  conversion  between 
different  character  sets  or  formats  on  the  client  and  database  server. 

The  Oracle  Net  foundation  layer  is  responsible  for  establishing  and 
maintaining  the  connection  between  the  FDSS  client  application  and  database  server,  as 
well  as  exchanging  messages  between  them  [14]. 

3,  Listener  Architecture 

The  database  server  receives  an  initial  connection  from  the  FDSS  client 
application  through  the  listener.  The  listener  is  an  application  positioned  on  top  of  the 
Oracle  Net  foundation  layer.  The  following  figure  (Figure  25)  illustrates  the  various 
layers  on  the  client  and  database  server  during  an  initial  connection. 
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Figure  25,  Layers  Used  iu  au  luitial  Couuectiou  (After  [14]) 

The  listener  brokers  the  FDSS  client  requests,  handing  off  the  requests  to  the 
Oracle  database  server.  Every  time  the  FDSS  client  requests  a  network  session  with  a 
database  server,  a  listener  receives  the  initial  request  [14]. 

Figure  26  shows  the  role  of  a  listener  during  connection  establishment  with  a 
client  making  a  TTC  connection: 
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(1)  The  database  registers  information  about  the  services,  instances,  and 
service  handlers  with  the  listener. 

(2)  The  client  makes  an  initial  connection  with  the  listener. 

(3)  The  listener  parses  the  client  request  and  forwards  it  to  the  service  handler 
for  the  database  service  requested. 
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Figure  26,  Listener  Architecture  (After  [14]) 

B.  OBJECT  MODEL  REPRESENTATION 

The  mapping  from  the  Conceptual  Data  Model  (CDM)  to  the  Object  Model 
consists  to  transform  CDM  objects  into  specified  object  language  objects  by  applying  the 
following  rules. 

1,  Independent  One-to-Many  Relationships 

In  independent  one-to-many  relationships,  the  primary  identifier  of  the  entity  on 
the  one  side  of  the  relationship  becomes  a: 

•  Primary  key  in  the  entity  on  the  one  side  of  the  relationship; 

•  Foreign  key  in  the  entity  on  the  many  side  of  the  relationship. 

2,  Dependent  One-to-Many  Relationships 

In  dependent  relationships,  the  primary  identifier  of  the  nondependent  entity 
becomes  a  primary/foreign  key  in  the  dependent  entity. 
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3,  Independent  Many-to-Many  Relationships 

In  independent  many-to-many  relationships,  the  primary  identifiers  of  both 
entities  migrate  to  a  join  entity  as  primary/foreign  keys. 

4,  Independent  One-to-One  Relationships 

In  independent  one-to-one  relationships,  the  primary  identifier  of  one  entity 
migrates  to  the  other  generated  entity  as  a  foreign  key. 


Conceptual  Data  Model 

Object  Oriented  Model 

Entity 

Class 

Association 

Relationship  or  association 

Binary  association  with  attributes 

Association  class 

Attribute 

Attribute 

Inheritance 

Generalization 

Table  2,  Transformation  of  a  CDM  to  an  OOM 


Figure  27,  Object  Model:  Registration 
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Figure  28,  Object  Model:  Transfer 


Figure  29,  Object  Model:  Maintenance 
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Figure  30,  Object  Model:  Retirement 


C.  DATABASE  SQL  SCRIPT 
CREATE  TABLE  Icat  ( 


codlin 

VARCHAR(15) 

PRIMARY  KEY, 

lab  lin 

VARCHAR(50), 

codusg 

VARCHAR(3), 

codsust 

VARCHAR(3), 

FOREIGN  KEY  (COD  USG)  REFERENCES  UCLASS  (COD  USG), 
FOREIGN  KEY  (COD  SUST)  REFERENCES  SCLASS(COD_SUST)); 

CREATE  TABLE  sclass  ( 

cod  sust  VARCHAR(3)  PRIMARY  KEY, 

labsust  VARCHAR(40)); 

CREATE  TABLE  uclass  ( 

cod  usg  VARCHAR(3)  PRIMARY  KEY, 

lab_usg  VARCHAR(20)); 
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CREATE  TABLE  cent  r eg  ( 

nbrreg 

VARCHAR(I5) 

PRIMARY  KEY, 

centdat 

DATE, 

holreg 

VARCHAR(40)); 

CREATE  TABLE  vehicle( 

nbr  lie 

VARCHAR(I5) 

PRIMARY  KEY, 

idveh 

VARCHAR(25), 

codlin 

VARCHAR(I5), 

fultyp 

VARCHAR(20), 

codunit 

VARCHAR(I5), 

num  tsht 

VARCHAR(20), 

nbrreg 

VARCHAR(I5), 

unit_prc 

DECIMAE(I2,3), 

geo_pos 

VARCHAR(40), 

FOREIGN  KEY  (COD  LIN)  REEERENCES  LCAT  (COD  LIN), 
EOREIGN  KEY  (COD  UNIT)  REEERENCES  lJNIT(COD_UNIT), 
EOREIGNKEY  (NUM  TSHT)  REEERENCES 


TECH_SHT(NUM_TSHT), 

EOREIGN  KEY  (NBR  REG)  REEERENCES  CENT  REG 
(NBRREG)); 


CREATE  TABLE  tech  sht  ( 


num  tsht 

VARCHAR(20) 

PRIMARY  KEY, 

dat  sht 

DATE, 

prosht 

VARCHAR(30)); 

CREATE  TABLE  reg  dept  ( 

coddept 

VARCHAR(8) 

PRIMARY  KEY, 

labdept 

VARCHAR(40), 

adrdept 

VARCHAR(40), 

teldept 

VARCHAR(I5)); 
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CREATE  TABLE  unit  ( 

cod  unit  VARCHAR(15)  PRIMARY  KEY, 

namunit  VARCHAR(40), 

coddept  VARCHAR(8), 

codarm  VARCHAR(8), 

adrunit  VARCHAR(50), 

telunit  VARCHAR(15), 

FOREIGN  KEY  (COD  DEPT)  REFERENCES  REG  DEPT 
(CODDEPT)); 

CREATE  TABLE  transf  bl  ( 


numbul 

VARCHAR(20) 

PRIMARY  KEY, 

datbul 

DATE, 

numtdec 

VARCHAR(20), 

codunit 

VARCHAR(15), 

FOREIGN  KEY  (NUM  TDEC)  REFERENCES  TRS  DEC 
(NUMTDEC), 

FOREIGN  KEY  (COD  UNIT)  REFERENCES  UNIT  (COD  UNIT)); 

CREATE  TABLE  trans  rq  ( 

numtrq 
codunit 
t_req_dt 

FOREIGN  KEY  (COD 

CREATE  TABLE  tr  rcLli( 

num_t_rq  VARCHAR(20), 

codlin  VARCHAR(15), 

qte_t_req  INTEGER, 

trrobs  VARCHAR(50), 

FOREIGN  KEY  (NUM  T  RQ)  REFERENCES  TRANS  RQ 
(NUMTRQ), 


VARCHAR(20)  PRIMARY  KEY, 
VARCHAR(15), 

DATE, 

UNIT)  REFERENCES  UNIT  (COD  UNIT)); 
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FOREIGN  KEY  (COD  EIN)  REEERENCES  LCAT  (COD  EIN), 
PRIMARY  KEY  (NUM  T  RQ,  COD  EIN)); 

CREATE  TABLE  trs  dec( 

num  tdec  VARCHAR(20)  PRIMARY  KEY, 

tdecdt  DATE, 

dtrsobs  VARCHAR(50)); 

CREATE  TABLE  dec  ln( 

numtdec  VARCHAR(20), 

numtrq  VARCHAR(20), 

codlin  VARCHAR(I5), 

objjdec  VARCHAR(50), 

qtetdec  INTEGER, 

EOREIGN  KEY  (NUMTDEC)  REFERENCES  TRSDEC 

(NUMTDEC), 

EOREIGN  KEY  (NUMTRQ)  REEERENCES  TRANSRQ 

(NUMTRQ), 

EOREIGN  KEY  (COD  EIN)  REEERENCES  ECAT  (COD  EIN), 
PRIMARY  KEY  (NUM  TDEC,  NUM  T  RQ,  COD  EIN  )); 

CREATE  TABLE  by  trans( 

numbul  VARCHAR(20), 

nbrlic  VARCHAR(I5), 

EOREIGN  KEY  (NUM  BUE)  REEERENCES  TRANSE  BE 
(NUMBUL), 

EOREIGN  KEY  (NBR  LIC)  REEERENCES  VEHICLE  (NBR  LIC), 
PRIMARY  KEY  (NUM  BUL,  NBR  LIC)); 

CREATE  TABLE  main_req( 


nummreq 
nbr  lie 


VARCHAR(20)  PRIMARY  KEY, 
VARCHAR(I5), 
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nbrmst  VARCHAR(12), 

m_req_dt  DATE, 

obsmreq  VARCHAR(50), 

FOREIGN  KEY  (NBR  EIC)  REFERENCES  VEHICEE  (NBR  EIC)); 


CREATE  TABLE  rep  bul( 

numrbul 
rbuldt 
nummreq 
FOREIGN  KEY 
(NUMMREQ)); 


VARCHAR(20)  PRIMARY  KEY, 
DATE, 

VARCHAR(20) 

(NUMMREQ)  REFERENCES  MAINREQ 


CREATE  TABLE  rep  ( 

numrbul  VARCHAR(20) 

ecuaet  VARCHAR(20), 

nbrhr  INTEGER, 

FOREIGN  KEY  (NUM  RBUL)  REFERENCES  REP  BUL 
(NUMRBUL), 

FOREIGN  KEY  (C  CU  ACT)  REFERENCES  CU  ACT  (C  CU  ACT), 
PRIMARY  KEY  (NUM  RBUL,  C  CU  ACT)); 


CREATE  TABLE  eu  act  ( 

ecuaet 
mculab 
mth  r  act 


VARCHAR(IO)  PRIMARY  KEY, 
VARCHAR(40), 

DECIMAL(12,3)); 


CREATE  TABLE  pre  bul( 

num_pr_b 

nbrlic 

prbtdt 

nwprdat 


VARCHAR(20)  PRIMARY  KEY, 
VARCHAR(15), 

DATE, 

DATE, 
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FOREIGN  KEY  (NBR  EIC)  REEERENCES  VEHICEE  (NBR  LIC)); 
CREATE  TABLE  perform( 

num_pr_b  VARCHAR(20), 

cd_p_act  VARCHAR(IO), 

pactqty  INTEGER, 

EOREIGN  KEY  (NUMPRB)  REEERENCES  PREBUE 
(NUMPRB), 

EOREIGN  KEY  (CDPACT)  REEERENCES 

PREV_ACT(CD_P_ACT), 

PRIMARY  KEY  (NUM  PR  B,  CD  P  ACT)); 

CREATE  TABLE  prev  act( 

cd_p_act  VARCHAR(IO)  PRIMARY  KEY, 

l_pr_act  VARCHAR(40), 

p_prt_mt  DECIMAE(I2,3)); 

CREATE  TABLE  ref  req( 

num  r  rq  VARCHAR(20)  PRIMARY  KEY, 

nbrlic  VARCHAR(I5), 

codunit  VARCHAR(I5), 

r_req_dt  DATE, 

mot_rf  VARCHAR(20), 

r_rq_obs  VARCHAR(50), 

EOREIGN  KEY  (COD  UNIT)  REEERENCES  UNIT  (COD  UNIT), 
EOREIGN  KEY  (NBR  EIC)  REEERENCES  VEHICLE  (NBR  LIC)); 

CREATE  TABLE  ref  dec ( 

nm  rf  dec  VARCHAR(20)  PRIMARY  KEY, 

num_r_rq  VARCHAR(20), 

rdecdt  DATE, 

o_rf_dec  VARCHAR(50), 
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FOREIGN  KEY  (NUM  R  RQ)  REEERENCES 
REE_REQ(NUM_R_RQ)); 

CREATE  TABLE  alie  bul( 


nmblal 
abuldt 
nmrfdec 
codadest 
EOREIGN  KEY 
(NMREDEC)); 


VARCHAR(20)  PRIMARY  KEY, 
DATE, 

VARCHAR(20), 

VARCHAR(IO), 

(NMREDEC)  REEERENCES  REEDEC 
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IV.  PROTOTYPE 


A,  COMMON  FUNCTIONALITIES 
1,  Connection 

To  start  the  FDSS  application  the  authorized  user  needs  to  connect  to  the  system. 
He  must  enter  his  user  name  and  password.  Figure  31  shows  the  process  of  connection  to 
the  system. 


Figure  31,  Connection  Screen 
2,  Common  Functionalities 

For  all  functionalities  of  the  system  the  standard  screen  shown  in  Figure  32  is 
implemented. 


Figure  32,  Standard  Screen 


Each  option  of  the  standard  screen  presents  a  set  of  functions  that  are  available  depending 
on  the  selected  option,  an  example  of  which  is  shown  in  Figure  33. 
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Figure  33,  Functions  Menu  Screen 

Under  the  Menu  Bar,  the  tools  bar  displays  a  set  of  ieons  representing  the  different 
functionalities  available  to  use  by  simple  clicking  using  the  mouse  (Figure  34). 


Figure  34,  Tool  Bar  Menu 


Besides  the  Tool  Bar,  the  standard  screen  presents  a  Status  Bar  on  the  bottom  of 
the  screen  that  indicates  the  current  option  in  use,  shown  below  in  Figure  35. 


Figure  35,  Status  Bar  Options 

B,  PRESENTATION  OF  THE  GENERAL  MENU 

The  following  menu  (Figure  36)  presents  the  software  developed  to  cover  the 
different  functionalities  of  the  FDSS  system. 
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Figure  36,  FDSS  Main  Menu 

1,  Registration  Module 
a.  Catalog  Screen 

The  screen  shown  in  Figure  37  presents  the  management  of  categories  of 

vehicles. 


Figure  37,  Catalog  Screen 
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b.  Usage  Class  Screen 

The  screen  shown  in  Figure  38  allows  add,  query,  update,  and  delete  a 
usage  class  of  a  vehicle. 


Figure  38,  Usage  Class  Screen 
c.  Sustain  Class  Screen 

The  screen  below  in  Figure  39  allows  the  user  to  add,  query,  update,  and 
delete  a  sustain  class  of  a  vehicle. 


Figure  39,  Sustain  Class  Screen 
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d.  Edit  Catalog  Screen 

The  following  screen  (Figure  40)  presents  the  option  for  editing  of 
categories  of  vehicles. 


SH  Oracle  Forms  Runtime  -  [FDSS] 


Action  Edit  Query  Block  Record  Field  Window  Help 

H  a  i  IF :  X  la  1  i  <-1  <  ► 


»  I  I  ? 


Vehicle  Category 


Category  Description 


Usage  Class 
Sustain  class 


Vehicle  Category 


Figure  40,  Edit  Criteria  Screen 


e.  Vehicle  Identification  Screen 

The  vehicle  identification  is  accessible  via  the  screen  shown  in  Figure  41. 


Oracle  Forms  Runtime  -  [FDSS] 


Action  Edit  Query  &ock  R^ecord  Reid  W^indow  Help 

H  a  «.a  !  If-  1  X  ®l  Hi  I  \  |  ? 


-  Vehicle  Identification  - 1 

License  ID 
Designation 
Category  Vehicle 
Fuel  Type 

Owner 

Technical  Sheet 
Register  ID 
Price  (DT) 


Figure  41,  Vehicle  Identification  Screen 
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f.  Central  Register  Screen 

The  screen  shown  in  Figure  42  allows  the  search  of  the  registers  of 
vehicles  and  their  holders. 


Figure  42,  Central  Register  Screen 
g.  Technical  Sheet  Screen 

The  screen  shown  in  Figure  43  allows  the  identification  of  military 
wheeled  and  tracked  vehicle  technical  sheet  producers. 
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Figure  43,  Technical  Sheet  Screen 

2,  Transfer  Module 

a.  Transfer  Request  Screen 

The  screen  in  Figure  44  allows  the  user  to  add  records  of  the  transfer 
request  of  military  wheeled  and  tracked  vehicles. 


Figure  44,  Transfer  Request  Screen 
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b.  Transfer  Decision  Screen 

The  screen  shown  in  Figure  45  allows  for  the  creation  of  transfer  decision 
records  of  categories  of  vehicles  assigned  to  units. 


Figure  45,  Transfer  Decision  Screen 
c.  Transfer  Bulletin  Screen 

The  screen  in  Figure  46  allows  the  assignment  of  tracked  and  wheeled 
vehicles  to  units. 
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Figure  46,  Transfer  Bulletin  Screen 

3,  Maintenance  Module 

a.  Preventive  Acts  Screen 

The  screen  shown  in  Figure  47  allows  the  user  to  add,  search,  update,  and 
delete  preventive  maintenance  acts. 


Figure  47,  Preventative  Maintenance  Acts  Screen 
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b.  Preventive  Maintenance  Bulletin  Screen 

The  screen  shown  in  Figure  48  allows  the  user  to  record  all  preventive 
maintenances  of  tracked  and  wheeled  vehicles. 


1  tS  Oracle  Forms  Runtime  -  [FDSS]  ^ 

§3  Action  Edit  Query  Block  Record  Field  Window  Help 

H  S  sa  1  i>  '  ^  li  ®  1  <4  4  ►  ►> 

9 

« 

Bulletin  Number 
License  Number 
Next  Maintenace  Date 


—  Preventive  Acts  - 

Act  Code 


Preventive  Maintenance  Bulletin  - 

_ I  Maintenance  Date  23-JAN-2007 


Designation 


Ouantity  Price 

I  I 


S. Total 


Figure  48,  Preventative  Maintenance  Bulletin  Screen 


c.  Curative  Acts  Screen 

The  screen  shown  in  Figure  49  allows  the  user  to  add,  search,  update,  and 
delete  curative  maintenance  acts. 
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Figure  49,  Curative  Maintenance  Acts  Screen 
d.  Maintenance  Request  Screen 

The  screen  shown  below  in  Figure  50  presents  an  application  to  start  the 
process  of  curative  maintenance  of  a  vehicle. 


Figure  50,  Curative  Maintenance  Request  Screen 
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4,  Inquiry 


Figure  51,  Military  Units  Screen 
b.  Regional  Department  Screen 

The  screen  shown  in  Figure  52  allows  the  user  to  search  for  the  regional 


Departments. 
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^  Oracle  Forms  Runtime  -  [FDSS] 


gD  Action  Edit  Query  Block  Record  Field  Window  Help 

H  ^  sg  I  If-*  1  X  1^1 1  <<<  4  ►  ^  \  ? 


-  Regional  Department  - 

Department  Code  _ | 

Department  Designation  _ | 

Department  Adress  _ | 

Phone  Number  _ I 


Figure  52,  Regional  Department  Screen 
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V.  SUMMARY  AND  CONCLUSION 


A.  SUMMARY 

This  thesis  developed  a  solution  to  provide  and  make  available  instantaneous  and 
aeeurate  information  that  will  be  used  to  derive  the  right  decision  on  time  regarding  the 
management  of  a  military  tracked  and  wheeled  vehicle  fleet.  Chapter  II  stated  the  system 
requirements  specification  and  analyzes  these  requirements.  Chapter  III  presented  the 
details  of  the  system  design  and  the  database  scheme.  Chapter  IV  provided  the  system 
prototype,  developed  using  the  Oracle  DBMS,  and  the  necessary  interfaces  for  the  users 
to  enhance  the  benefits  of  this  software.  This  study  will  improve  the  decision  making 
ability  of  the  leader  of  this  department.  It  will  make  the  routine  tasks  easier,  and  enforce 
the  control  process  concerning  the  usage  and  maintenance  of  military  vehicles. 

B.  INFORMATION  SYSTEM 

A  major  challenge  in  developing  a  thorough  Fleet  Decision  Support  System  is 
finding  what  information  is  available.  What  information  will  be  needed  to  meet  the 
requirements?  And  how  this  information  will  be  presented  to  the  end-user?  The  best 
people  to  answer  these  questions  are  those  who  are  knowledgeable  about  fleet 
management  and  are  part  of  the  information  system.  Moreover,  the  greatest  success  in 
implementing  this  kind  of  information  system  relies  on  an  effective  plan  that  provides  an 
incremental  but  continuous  integration  of  new  functionalities.  These  new  functionalities 
should  apply  to  both  the  core  fleet  management  information  system  and  to  ancillary  tools 
that  complement  and  enhance  it. 

C.  PLATFORM  AND  NETWORK  CONSIDERATIONS 

Another  major  consideration  in  developing  a  Fleet  Decision  Support  System 
relates  to  the  platform  that  will  be  utilized  to  deliver  tools  to  end  users.  There  are  a 
variety  of  platforms  available  today.  However,  client  server  architecture  and  the  Intranet 
are  clearly  dominating  the  technology  industry  as  the  platforms  of  choice.  The  principal 
virtue  of  these  platforms  is  that  they  facilitate  the  efficient  and  inexpensive  distribution 
and  maintenance  of  applications  to  multiple  end  users.  They  also  support  another  trend 
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that  promises  to  further  ehange  the  definition  of  effeetive  fleet  management:  providing 
real-time  access  for  fleet  users  to  the  detailed  information  that  historically  has  been 
available  only  to  fleet  managers. 

D,  RECOMMENDATIONS 

Several  future  tasks  that  need  to  be  completed  are  as  follows: 

•  Development  of  the  curative  maintenance  and  retirement  subsystems. 

•  Development  of  a  module  related  to  the  inventory  of  tracked  and  wheeled 
vehicles  of  units. 

•  Test  and  integrate  the  newly  developed  subsystems  and  modules  to  the 
system. 

•  Test  the  entire  system  and  verify  the  behavior  of  each  subsystem. 

•  Train  the  users  to  use  and  interact  with  the  system  properly. 

•  The  software  maintenance  phase  will  determine  the  success  of  this  project. 
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APPENDIX.  DATA  DICTIONARY 


Data  Element  Name 

Field  Name 

Code  Format 

Address  regional  department 

adrdept 

VarChar(40) 

Address  unit/regiment 

adr  unit 

VarChar(50) 

Alienation  bulletin  date 

abuldt 

Date 

Alienation  bulletin  number 

nm  al  bl 

VarChar(20) 

Alienation  code  destination 

codadst 

VarChar(lO) 

Central  register  date 

centdat 

Date 

Central  register  number 

nbrreg 

VarChar(15) 

Code  Army 

codarm 

VarChar(2) 

Code  curative  act 

ccuact 

VarChar(lO) 

Code  line  of  catalog 

codlin 

VarChar(15) 

Code  preventive  act 

cd_p_act 

VarChar(lO) 

Code  regional  department 

coddept 

VarChar(8) 

Code  sustain 

codsust 

VarChar(3) 

Code  unit/regiment 

codunit 

VarChar(15) 

Code  usage 

codusg 

VarChar(3) 

Curative  maintenance  act  label 

m  cu  lab 

VarChar(40) 

Decision  transfer  request  observation 

dtrobs 

VarChar(50) 

Department  telephone 

teldept 

VarChar(15) 
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Data  Element  Name 

Field  Name 

Code  Format 

Description  of  work 

wk_desc 

VarChar(50) 

Fuel  type 

fultyp 

VarChar(20) 

Designation  vehicle 

geo_pos 

VarChar(25) 

Label  Line  catalogue 

lab  lin 

VarChar(50) 

Label  regional  department 

labdept 

VarChar(40) 

Label  sustain 

labsust 

VarChar(40) 

Label  Usage 

labusg 

VarChar(20) 

License  number 

nbr  lie 

VarChar(15) 

Maintenance  request  date 

m_req_dt 

Date 

Maintenance  request  number 

num  mreq 

VarChar(20) 

Maintenance  request  observation 

obsmreq 

VarChar(50) 

Maintenance  station  number 

nbr  m  st 

VarChar(12) 

Maintenance  vital  sheet  number 

sht  num 

VarChar(15) 

New  preventive  maintenance  date 

nw_pr_dt 

Date 

Preventive  act  label 

l_pr_act 

VarChar(40) 

Preventive  act  quantity 

Pactqty 

Integer 

Preventive  bulletin  date 

prbldt 

Date 

Preventive  bulletin  number 

num_pr_bl 

VarChar(20) 

Preventive  bulletin  total  amount 

pr  b  amt 

Decimal(12,3) 
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Data  Element  Name 

Field  Name 

Code  Format 

Preventive  maintenanee  aet  amount 

p_prt_mt 

Deoimal(12,3) 

Retirement  deeision  date 

rdeedt 

Date 

Retirement  deeision  number 

nm  rf  dee 

VarChar(20) 

Retirement  Deeision  Objeet 

orfdee 

VarChar(50) 

Retirement  motivation 

mot  rf 

VarChar(20) 

Retirement  request  date 

r_req_dt 

Date 

Retirement  request  number 

num  r  rq 

VarChar(20) 

Retirement  request  observation 

r_rq_obs 

VarChar(50) 

Regional  department  address 

adrdpt 

VarChar(40) 

Register  holder 

holreg 

VarChar(40) 

Repair  aet  amount 

mt  r  aet 

Deeimal(12,3) 

Repair  bulletin  date 

rbuldt 

Date 

Repair  bulletin  number 

numrbul 

VarChar(20) 

Technieal  sheet  produeer 

prosht 

VarChar(30) 

Teehnieal  sheet  date 

dat  sht 

Date 

Teehnieal  sheet  number 

num  tsht 

VarChar(20) 

Teehnieian’s  lieense  number 

nubltee 

VarChar(25) 

Total  eurative  maintenanee  amount 

tot  cu  amt 

Deeimal(12,3) 

Total  preventive  maintenanee  amount 

tot_pr  amt 

Deeimal(12,3) 
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Data  Element  Name 

Field  Name 

Code  Format 

Total  repair  amount 

t  rp  amt 

Decimal(12,3) 

Track/vehicle  Designation 

geo_pos 

VarChar(40) 

Transfer  bulletin  date 

datbul 

Date 

Transfer  bulletin  number 

numbul 

VarChar(20) 

Transfer  decision  date 

tdecdt 

Date 

Transfer  decision  number 

numtdec 

VarChar(20) 

Transfer  decision  object 

objtdec 

VarChar(50) 

Transfer  decision  quantity 

qtetdec 

Integer 

Transfer  request  date 

t_req_dt 

Date 

Transfer  request  number 

numtrq 

VarChar(20) 

Transfer  request  observation 

tr  r  obs 

VarChar(50) 

Transfer  request  quantity 

qtetreq 

Integer 

vehicle  unit  price 

unit_prc 

Decimal  (12,3) 

Unit  telephone 

tel  unit 

VarChar(15) 

Unit/regiment  name 

nam  unit 

VarChar(40) 

Vehicle  id  number 

idveh 

VarChar(25) 
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